home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
- IEN 158 Jack Haverty
- Bolt Beranek and Newman
- 1 October 1980
-
-
-
- XNET Formats for Internet Protocol Version 4
- Jack Haverty
- Bolt Beranek and Newman Inc.
- October 1,1980
-
-
- This IEN is intended to capture in print the formats used
-
- currently in the version 4 XNET protocol; most of the data is
-
- courtesy of Ray Tomlinson.
-
-
- Version 4 XNET is identical with version 2.5 XNET with the
-
- exceptions listed below. The version 2.5 format is described in
-
- RFC 643. It should be noted that the manner in which the
-
- protocol is used by a user program (such as the PDP10 XNET
-
- program), and by the various target-machine XNET servers, is not
-
- defined herein. In particular there are several problems and
-
- heuristics in dealing with the operation of the protocol in the
-
- internet environment, where individual packets may be duplicated,
-
- lost, and reordered.
-
-
- Changes from the version 2 formats include the following:
-
- 1) XNET header and data is embedded in a IN V4 packet instead of
- a V2.5 packet.
-
- 2) Packet format changed to add Port, Sequence number, and
- Checksum fields.
-
- 3) Change in asynchronous reply codes.
-
- 4) Addition of ACK bit to opcode field.
-
- 5) Positive acknowledgement of all messages.
-
-
-
-
-
-
- IEN 158 Jack Haverty
- Bolt Beranek and Newman
- 1 October 1980
-
-
-
-
-
- Packet Format
-
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- ! Port !
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- ! LSB Sequence MSB !
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- ! Checksum !
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- ! PID !CNT!ACK! Opcode !
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- ! LSB Argument 1 MSB !
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- ! LSB Argument 2 MSB !
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- ! !
- ! Data !
- ! !
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
- The IN protocol is set to the XNET protocol number (17 octal).
-
- Host to target opcodes
-
- NOP 0 No operation.
- DEBUG 1 Start debugging a process or address space.
- ENDBUG 2 End debugging a process or address space.
- HALT 3 Halt the process.
- DPOSIT 4 Deposit in memory.
- RESUME 5 Resume execution of a process.
- EXAM 6 Examine memory.
- DSV 7 Deposit state vector (r0-r5,sp,pc,ps).
- SETBPT 10 Set breakpoint.
- REMBPT 11 Remove breakpoint.
- ONESTP 12 Single step process (using trace trap).
- PROCD 13 Proceed from breakpoint.
- CREAP 14 Create a new process (or address space).
- DSTROY 15 Destroy (delete) a process or address space.
- XIOREP 16 Reply to XIO output (not used anymore).
- XINREP 17 Reply to XIO input.
- DEFALL 20 Define and allocate memory to an address space.
- SAP 21 Start all processes.
- SAVDSK 22 Save on disk.
- GETDSK 23 Get from disk.
- ENTRST 24 Enter address space into restart table.
-
-
-
-
-
-
- IEN 158 Jack Haverty
- Bolt Beranek and Newman
- 1 October 1980
-
-
-
-
- Opcodes from target to host machine.
-
- HALTED 77 Process halted (FREEP with arguments of 0).
- TRAPPED 76 Process trapped due to error.
- TTRAP 75 Trace trap.
- BPT 74 Breakpoint hit.
- XIOIN 73 XIO input request.
- XIOOUT 72 XIO output request.
-
-
- Checksum
-
-
- The checksum is the same as that for the IN header; ones
-
- complement of ones complement sum of words in the packet from
-
- Port field to last data word inclusive. In case of an odd number
-
- of data bytes, an additional byte of zeroes is assumed for
-
- checksum purposes.
-
-
- Port number
-
-
- The port number is a unique number relative to the host
-
- machine which appears in every packet for a particular debugging
-
- session. It is suggested that this number be derived from the
-
- time of day so that each session will be unique over a long
-
- period of time.
-
-
- Sequence number
-
-
- The first packet of a session (first use of a particular
-
- port number) is numbered 0. Subsequent packets increment by 1
-
- modulo 2**16. Packets initiated by the target machine (opcodes
-
-
-
-
-
-
- IEN 158 Jack Haverty
- Bolt Beranek and Newman
- 1 October 1980
-
-
-
- 72-77) are also numbered starting from 0. The target machine is
-
- allowed to execute packets out of order but must never execute a
-
- packet twice unless the effect is harmless. For example, an
-
- examine packet should be re-executed so that the data may be
-
- returned to the sender. Deposit or resume should not be re-
-
- executed. The host machine is responsible for correct ordering
-
- of critical functions. For example, it must not send a RESUME
-
- command until all prior deposits have been acknowledged.
-
-
- Acknowledgements
-
-
- Each packet must be acknowledged by the receiver. An
-
- acknowledgement consists of the original header plus any
-
- requested data (e.g. EXAM) with the ACK bit set.
-
- Acknowledgements are not cumulative; an acknowledgement
-
- acknowledges only the one packet with the matching sequence
-
- number. If the target debugger is incapable of performing the
-
- requested function, it should set the CNT (can't) bit instead of
-
- the ACK bit. Both bits may be set meaning that the function is
-
- available but the data required is no longer available. This
-
- might be the result of a duplicate packet.
-
-
-
-
-
-
-
-
-